Cuando Google publicó la primera versión de SLSA en 2021, la cadena de suministro de software todavía era un tema relativamente marginal. SolarWinds acababa de convertir la preocupación en urgencia, pero las herramientas eran escasas y los estándares estaban en borrador. Cuatro años después, el panorama es muy distinto: SLSA v1.0 lleva año y medio publicada, el ecosistema de Sigstore ha madurado, las forjas principales ofrecen generación de atestaciones con un par de líneas de configuración, y la regulación europea empieza a citar todo esto con nombres y apellidos en borradores como la Cyber Resilience Act.
Es un buen momento para hacer balance. Este repaso no pretende ser exhaustivo, sino responder a la pregunta que me he encontrado varias veces estos meses: «Queremos empezar con SLSA, ¿por dónde?».
Qué cambió en la v1.0
La versión inicial de SLSA mezclaba requisitos de fuente, de compilación y de dependencias en una única escalera de cuatro niveles. Era conceptualmente elegante pero difícil de aplicar: un equipo podía tener una compilación impecable y una gestión de dependencias mediocre, y el marco no sabía qué hacer con él.
La v1.0 separó las preocupaciones en pistas (tracks). Hoy la pista de compilación (Build) es la única estabilizada, con tres niveles:
- L1 pide que la compilación esté automatizada y que exista una declaración de procedencia básica.
- L2 añade que esa procedencia se firme y se publique por un servicio de compilación hospedado.
- L3 exige aislamiento fuerte entre compilaciones y que las claves no sean accesibles desde el código que se construye.
Las pistas de fuente y dependencias siguen en redacción. Esto es sano: admite que el problema es demasiado grande para un único modelo, y deja a los equipos empezar por lo más tangible sin esperar a un marco completo que nunca llegaría.
Lo que funciona bien
Si tu compilación vive en GitHub Actions, el camino hasta L2 es sorprendentemente corto. La acción oficial de generación de procedencia produce una atestación firmada con Sigstore, y el proveedor del runner firma como identidad verificable. En proyectos que usan GoReleaser, la integración con cosign y la subida de atestaciones al registro están empaquetadas en la configuración por defecto desde hace varias versiones.
El ecosistema Sigstore en general ha sido el gran desbloqueo. Hace tres años firmar binarios implicaba gestionar claves, HSM y procedimientos que pocos equipos podían permitirse. Hoy una identidad de OIDC basta para emitir una firma corta y registrarla en un transparency log público. El cambio de modelo mental (firmas efímeras en lugar de claves de larga duración) ha hecho que la práctica se extienda sin fricción.
La verificación también ha mejorado. Tanto cosign verify-attestation como las políticas de admisión en Kubernetes con Kyverno o Gatekeeper permiten exigir que una imagen tenga procedencia firmada por un flujo de trabajo concreto antes de dejarla entrar al clúster. Esto convierte SLSA en algo ejecutable, no solo documental.
Lo que sigue costando
El nivel L3 es otra historia. Exige aislamiento efectivo entre compilaciones, lo que implica o bien usar un proveedor que ya lo garantice (Google Cloud Build con ciertos modos, o los runners efímeros de GitHub con configuraciones específicas) o construir infraestructura propia no trivial. Para la mayoría de equipos pequeños, subir de L2 a L3 no es rentable comparado con otras prioridades de seguridad.
Las compilaciones multi-etapa con contenedores intermedios también dan quebraderos de cabeza. Si tu Docker build usa capas construidas fuera del flujo con SLSA, tu procedencia final es técnicamente correcta pero incompleta: certifica cómo se ensambló la imagen, no cómo se construyeron las dependencias intermedias. Llegar a una cadena completa requiere que cada eslabón firme, y ahí es donde la adopción irregular del ecosistema se nota.
Otro punto delicado es el de los monorepos grandes con múltiples artefactos. La procedencia se emite por artefacto, pero si 30 servicios comparten la misma pipeline, el coste de generar y firmar 30 atestaciones en cada push no es despreciable. Hay trabajo en curso para permitir procedencias agregadas, pero todavía no está estandarizado.
Dónde empezar sin frustrarse
Si no has tocado SLSA todavía, mi recomendación es concreta. Elige un solo artefacto importante, el que más te preocuparía que fuera comprometido: el binario del producto, la imagen base que todo el mundo hereda, la librería interna que se usa en varios servicios. Conseguir L1 para ese único artefacto es cuestión de dos horas si ya compilas en CI. Conseguir L2 suma quizá otra hora para activar la firma y configurar el registro de atestaciones.
Con ese único caso resuelto, habrás aprendido el vocabulario (procedencia, atestación, transparency log, verificación en admisión) y tendrás un ejemplo interno del que copiar. Extender a más artefactos pasa a ser mecánico.
Lo que no recomendaría es intentar alcanzar L3 en todo de golpe, ni construir un marco de cumplimiento SLSA antes de tener siquiera un artefacto firmado. La experiencia habitual es que el equipo se atasca en planificación y nunca llega a ejecutar nada verificable.
Mirando hacia adelante
La siguiente frontera, la pista de fuente, es la que más impacto real tendría. Garantizar que el código que entra en compilación viene realmente del repositorio que dice venir, y que ha pasado por las revisiones declaradas, cubriría el vector de ataque que abrió SolarWinds. Los borradores actuales apuntan en buena dirección, pero su dependencia de detalles internos de las forjas hace que el despliegue vaya a ser necesariamente desigual.
Mientras tanto, la pista de compilación en L2 generalizada ya cambia el juego. Convierte la pregunta «¿puedo confiar en este binario?» en «¿encaja su procedencia con lo que esperaba?», y eso es algo que una política automatizada sí puede responder. Es menos ambicioso que la visión original de SLSA, pero es ejecutable hoy, y eso vale más que cualquier nivel que solo exista en diapositivas.
